rt_tick_t 的意义不就是用来做 timeout 吗... 一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。

补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX) 以及 RT_WAITING_FOREVER.

rt_tick_t 的意义不就是用来做 timeout 吗...一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。

补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX） 以及 RT_WAITING_FOREVER.

RT_WAITING_FOREVER 就是负值，核心代码中 timeout 的类型也是使用的 rt_int32_t 。从类型名 rt_int32_t 看来确实有不能直观分辨数值单位的问题，但对于 rt_tick_t 无符号类型的风险更要重视！不知道 rt_tick_t 改为有符号的是否更好？

rt_tick_t 的意义不就是用来做 timeout 吗...一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。
补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX） 以及 RT_WAITING_FOREVER.

RT_WAITING_FOREVER 就是负值，核心代码中 timeout 的类型也是使用的 rt_int32_t 。从类型名 rt_int32_t 看来确实有不能直观分辨数值单位的问题，但对于 rt_tick_t 无符号类型的风险更要重视！不知道 rt_tick_t 改为有符号的是否更好？

首先从这个 API 的设计层面上 RT_WAITING_FOREVER 是什么值不重要。重要的是这个值存在且区分于其它 tick 可取值。常量表达式 -1 只能说是一个实现。我也可以实现为 ((rt_tick_t)-1)。

其次，我主要想表达的是 timeout 最好是一个有语义的类型。至于是否是有符号类型，这是另一件事情了。这个与其改 rt_tick_t 不如加个新的 timeout 类型，因为 rt_tick_t 在 64 位平台本来有意义的范围就很小了。

#8789

sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。

sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。

所以是想搞个新的类似 rt_timeout_t 类型，专门用来做 tick，参考 #8789 。考虑兼容的话，可以定义为带符号的 rt_base_t 。

rt_timer内部都是用的rt_tick_t，所以这里用rt_tick_t是没问题的。即便是要统一也是从rt_timer开始，仅仅改这里没有意义。
可以先解决当前的编译告警问题，改为(rt_tick_t)RT_WAITING_FOREVER.

统一用 rt_tick_t
#deinfe RT_WAITING_FOREVER ((rt_tick_t)-1)

rt_tick_t 为无符号整数，可以是 32bit, 也可以是64bit